Computer users input information into the computer from various input devices, including a keyboard, mouse and pen input device. Problems arise when the processing of one type of input is slow relative to another. In particular, when processing handwritten characters input via the pen device, the handwriting recognition (translation) process takes a relatively substantial amount of time compared to other types of input, including other types of pen-initiated messages. Indeed, while one or more characters are being translated, the user can input additional information which is intended to impact the pending character or characters, but may wind up operating on others.
By way of example, if a user writes the string "ABC" into a handwriting input area and then enters the BackSpace key, (either via a conventional keyboard or by touching the pen to a displayed, virtual BackSpace key), the BackSpace key message may be received and handled before the "C" is done processing. If this timing problem occurs, the "B" character, and not the "C" character, is erased, because information is handled in the order it is processed rather than the order it is input. Similarly, if the user writes a string such as "DEF," and then, while the "F" is being recognized, moves the input focus (cursor) to between the "D" and "E," the string will be recognized by the application program as "DFE" instead of the intended "DEF."
The reason that the input is handled in the order processed rather than the order received is that it is even less desirable to wait until character recognition is complete before handling subsequent input information. More particularly, if the user writes a stroke with a pen but does not receive rapid visual feedback on the pen input display area, (because a previously-input character is still being translated), the user tends to rewrite the stroke, adding another, unwanted stroke to the input queue. Having the pen temporarily appear to "run out of ink" and then suddenly recover is extremely frustrating to the user. Even more frustrating, however, is to have the system not only appear to recover at some later stroke, but restore any previous strokes that were not displayed earlier.
As a result, one approach to these above problems has been to ignore further input until the previous character is recognized. This avoids the stroke-rewriting problem, but slows the user down to the speed of recognition and thus frequently makes it appear as if the application is temporarily frozen. An alternative approach has been to accept the above-described timing problems (and other related problems) and hope the user adapts to the system by not providing further input until after appropriate visual feedback, such as indicative of complete character recognition, is received. In short, both approaches are poor tradeoffs, as the former makes the system look and act inferior, while the latter forces the user to learn and follow undesirable rules else risk inputting something other than intended.